Epic and ARM : user's guide

We give a brief introduction to Epic and to ARM (they are discussed in more detail elsewhere). We show how to use the Epic compiler and how to execute ARM code. Then we describe ARM's API (application programmer's interface) which allows ARM to be used as a plug-in library. We describe how to access external functions from ARM and how to add external data types

Lazy rewriting on eager machinery

We define Lazy Term Rewriting Systems and show that they can be realized by local adaptations of an eager implementation of conventional term rewriting systems. The overhead of lazy evaluation is only incurred when lazy evaluation is actually performed. Our method is modelled by a transformation of term rewriting systems, which concisely expresses the intricate interaction between pattern matching and lazy evaluation. The method easily extends to term graph rewriting

Minimal term rewriting systems

Formally well-founded compilation techniques for Term Rewriting Systems (TRSs) are presented. TRSs are compiled into Minimal Term Rewriting Systems (MTRSs), a subclass of TRSs in which all rules have an extremely simple form. A notion of simulation of (rewrite) relations is presented, under which an MTRSs can be said to simulate a TRS. The MTRS rules can be directly interpreted as instructions for an extremely simple Abstract Rewriting Machine (ARM). Favourable practical results have already been obtained with an earlier version of ARM

A model for I/O in equational languages with don't care non-determinism

Existing models for I/O in side-effect free languages focus on functional languages, which are usually based on a largely deterministic reduction strategy, allowing for a strict sequentialization of I/O operations. In concurrent logic programming languages a model is used which allows for don't care non-determinism; the sequentialization of I/O is extensional rather than intensional. We apply this model to equational languages, which are closely related to functional languages, but exhibit don't care non-determinism. The semantics are formulated as constrained narrowing, a relation that contains the rewrite relation, and is contained in the narrowing relation. We present constrained narrowing and some of its properties; a constructive method to transform conventional term rewriting systems to constrained narrowing systems; and a discussion on requirements for an implementation

Epic 1.0 (unconditional) : an equational programming language

We present EPIC, an equational programming language: its abstract syntax, static and operational semantics, and one of many possible concrete grammars of unconditional EPIC

ARM : abstract rewriting machine

Term rewriting is frequently used as implementation technique for algebraic specifications. In this paper we present the abstract term rewriting machine (ARM), which has an extremely compact instruction set and imposes no restrictions on the implemented TRSs. Apart from standard conditional term rewriting, associative lists are supported. ARM code is translated to (ANSI) C; the resulting execution speeds are good (on a sun4, an average of 80000 rewriting steps per second and a maximum of 416000 r/s were measured). Several benchmarks are shown, and related work is discussed in depth

Simulating TRSs by minimal TRSs : a simple, efficient, and correct compilation technique

A simple, efficient, and correct compilation technique for left-linear Term Rewriting Systems (TRSs) is presented. TRSs are compiled into Minimal Term Rewriting Systems (MTRSs), a subclass of TRSs, presented in [KW95d]. In MTRSs, the rules have such a simple form that they can be seen as instructions for an easily implementable abstract machine, the Abstract Rewriting Machine (ARM). In the correctness proof, it is shown that the MTRS resulting from compilation of a TRS simulates neither too much (soundness) nor too little (completeness), nor does it introduce unwarranted infinite sequences (termination conservation). The compiler and its correctness proof are largely independent of the reduction strategy

An extensible language for the generation of parallel data manipulation andcontrol packages

The design and implementation of the language fSDL (full Structure Definition Language) is discussed. In fSDL, complex user-defined data types such as lists, tables, trees, and graphs can be constructed from a tiny set of primitives. Beyond mere structure definitions (also offered by previously existing tools) high-level functionality on these data types can be specified. In the COMPARE (ESPRIT) project, the C code generated from an fSDL specification will be used by compiler-components running in parallel on a common data pool. fSDL is first translated into a sublanguage, flat fSDL, from which the actual C code is produced. Flat fSDL is a convenient interface for cooperation with other compiler generation tools. There is a formal relation between the input fSDL and the resulting flat form

Within ARM's reach : compilation of left-linear rewrite systems via minimalrewrite systems

A new compilation technique for left-linear term rewriting systems is presented, where rewrite rules are transformed into so-called minimal rewrite rules. These minimal rules have such a simple form that they can be viewed as instructions for an abstract rewriting machine (ARM)

Benchmarking implementations of functional languages with ‘Pseudoknot', a float-intensive benchmark

Over 25 implementations of different functional languages are benchmarked using the same program, a floating-point intensive application taken from molecular biology. The principal aspects studied are compile time and execution time for the various implementations that were benchmarked. An important consideration is how the program can be modified and tuned to obtain maximal performance on each language implementation. With few exceptions, the compilers take a significant amount of time to compile this program, though most compilers were faster than the then current GNU C compiler (GCC version 2.5.8). Compilers that generate C or Lisp are often slower than those that generate native code directly: the cost of compiling the intermediate form is normally a large fraction of the total compilation time. There is no clear distinction between the runtime performance of eager and lazy implementations when appropriate annotations are used: lazy implementations have clearly come of age when it comes to implementing largely strict applications, such as the Pseudoknot program. The speed of C can be approached by some implementations, but to achieve this performance, special measures such as strictness annotations are required by non-strict implementations. The benchmark results have to be interpreted with care. Firstly, a benchmark based on a single program cannot cover a wide spectrum of ‘typical' applications. Secondly, the compilers vary in the kind and level of optimisations offered, so the effort required to obtain an optimal version of the program is similarly varie